Prolog and abduction 4 writing garbage collectors

It seems silly and impractical: to write a garbage collector (for a Prolog engine) in Prolog itself. However, there are at least three advantages in doing so: (1) one gets a runnable specification of the garbage collector, (2) it can enhance understanding of the algorithms involved without having to worry about gory pointer details, (3) the garbage collector written in Prolog can be used for debugging its implementation in a lower level language. We show how a sliding collector can be specified in Prolog in a reasonably declarative way, how it can be executed best within a tabling environment, and how it was of use during the development of the heap garbage collectors of BinProlog, XSB and more recently ilProlog. We indicate how the Prolog implementation can reconstruct the classical Morris algorithm. We also specify the garbage collection process in an abductive formalism and speculate on how constraints on the abductive solver can retrieve well-known algorithms. Prolog and Abdu tion 4 writing Garbage Colle tors Bart Demoen Department of Computer S ien e Katholieke Universiteit Leuven B-3001 Heverlee, Belgium bmd s.kuleuven.a .be Abstra t. It seems silly and impra ti al: to write a garbage olle tor( for a Prolog engine) in Prolog itself. However, there are at least three advantages in doing so: (1) one gets a runnable spe i ation of the garbage olle tor, (2) it an enhan e understanding of the algorithms involved without having to worry about gory pointer details, (3) the garbage olle tor written in Prolog an be used for debugging its implementation in a lower level language. We show how a sliding olle tor an be spe i ed in Prolog in a reasonably de larative way, how it an be exe uted best within a tabling environment, and how it was of use during the development of the heap garbage olle tors of BinProlog, XSB and more re ently ilProlog. We indi ate how the Prolog implementation an re onstru t the lassi al Morris algorithm. We also spe ify the garbage olle tion pro ess in an abdu tive formalism and spe ulate on how onstraints on the abdu tive solver an retrieve well-known algorithms. 1 Introdu tion This work originates from our involvement in writing garbage olle tors for di erent systems: in the mideighties, it was for BIM Prolog 1, in 1994 for BinProlog ([5℄) and from 1996 on for XSB ([7℄,[8℄). More re ently, we wrote a heap garbage olle tor for ilProlog (see [6℄). Be ause of the roots of our work, the setting of the urrent paper is garbage olle tion of a WAM heap or global sta k as it is also named. Therefor, we will assume some knowledge of WAM: see for instan e [1℄. Also some knowledge of the algorithms des ribed in [10℄, [4℄ and of heap garbage olle tion for Prolog in general, e.g. from [2℄, [3℄, will be helpful. One re urring problem in the implementation of su h garbage olle tors is of ourse debugging them: one is bound to make errors in the pointer ddling involved and also, the adaptations to one's own need of the algorithms in literature, an be erroneous in a way that is only dis overed after the C ode has been written. This is often aused by the fa t that memory management is added as an after-thought to the system and partly be ause usually one does not understand at all the usefulness logi of a system until one gets down to implementing a (pre ise) garbage olle tor for it. One popular way to debug is to insert print statements all over in the sour e ode. Also debugging tools like gdb or dbxtool an be handy, but they are notoriously unhelpful in debugging problems that show up in another part of the ode than where the bug really is. Also, hexade imal memory dumps (whi h su h tools give you easily) are not the most pleasant obje ts to deal with and a t like the proverbial haysta k. Still, bugs must be found. And when a bug or set of bugs annot be eliminated, the ultimate resort might be to rewrite the ode from s rat h: this a tually happened in the BIM Prolog proje t. In 1994, about 10 years after the BIM Prolog experien e, we went into implementing the garbage olle tors for BinProlog [5℄: Geert Engels gave it a very good rst shot in the ontext of his engineering thesis 2, but we knew that debugging would ome in sooner or later, espe ially sin e BinProlog has features like a bla kboard, ndall bubbles in the heap, ba ktra kable destru tive assignment and term ompression. We anti ipated that a de ent sta k dump would be ru ial and we then already hose a Prolog format: heap, hoi e point sta k and trail (BinProlog has no environment sta k) ould at any moment be dumped in the form of Prolog fa ts. We bene tted greatly from the sta k dumps in Prolog format, but we 1 now named MasterProLog 2 masters level elsewhere didn't really use them mu h for debugging the garbage olle tors, be ause Geert Engels did a very good job. When we started implementing the XSB olle tor in 1996, we a tually rst (re)implemented the sta k expansion routines as a warm up to get used to the XSB ma ros, tagging s hema et .. Unfortunately (but not unexpe tedly) we even needed to debug our sta k expansion routines not just be ause they were buggy, but mainly be ause the invariants we were lead to believe were not respe ted by the rest of the implementation or plainly undo umented and forgotten by the rest of the team. XSB did have fun tions for dumping the sta ks in a symboli way and they were of some help. But we were missing something: the dumps ould be looked at by humans, but ould not easily be treated with programmable tools like Prolog. Basi ally the format of the dump was wrong: it should have been in Prolog syntax be ause that allows easy general pro essing, in parti ular, dumps in Prolog syntax an be onsulted. So we hanged the sta k dump routines to produ e output in the form of Prolog fa ts. We'll give some more details on the Prolog format later and how we used it. The point about syntax seems very trivial and to some extent it is of ourse. But without this last step in the series of trivial steps from a hexade imal ore dump, over some human readable form to Prolog fa ts, we would have made no progress in this area, as Prolog is for us the main universal programming tool. And more bugs in our garbage olle tors would have survived for a longer time. The rst use of these Prolog dumps of sta ks was just for onsisten y he king in the ontext of the expansion routines: does the expanded sta k have as many live ells as the original; are they in the same order; is every pointer relo ated orre tly ... Some of them are simple he ks that ould have been performed in a di erent way, but the Prolog format made life already easier. Later we used the Prolog dumps for he king the garbage olle tion pro ess: are there as many surviving ells as marked ones; are all root pointers redire ted appropriately 3 et .. Su h simple properties an be he ked with simple read non-re ursive Prolog queries on the dumps. But the more we used the sta k dumps, the more we appre iated their usefulness and we started asking queries that involve re ursion: e.g. is every rea hable ell also marked ? And we be ame aware of the fa t that these more ompli ated queries ould only naturally be asked in a tabling environment. So it was very fortunate that we were working in and with XSB at that time. After some time, we de ided not just to he k dumps but also to olle t dumps, i.e. given a dump of the sta ks before the garbage olle tion, produ e independently of the a tual olle tion a dump of the olle ted heap and then ompare with what the real garbage olle tor produ ed. So the idea o urred to us that the olle tor itself an be spe i ed and exe uted in Prolog, as a shadow and spe i ation of the real one written in C and as a guarding angel, or wat h dog, for the latter. In later se tions we des ribe a heap garbage olle tor for Prolog and how it was (or ould have been) used for debugging. Indeed, our des ription will be a mixture of what we a tually did and how we now think it should/ ould have been done: it is not relevant or produ tive to make the distin tion ex ept for historians. Also, we'll onfuse what happened during the development of BinProlog, XSB and ilProlog. Having a garbage olle tor spe i ed in Prolog is ni e, but not ompletely satisfa tory: when several algorithms are used in the implementation 4, one needs to write more than one Prolog program to mimi them. The other disadvantage of the Prolog program is that its orre tness however mu h more obvious than the orre tness of the orresponding C ode must be established. So we wanted a more generi spe i ation of the garbage olle tion pro ess in logi and one that allows a higher on den e in its orre tness. Be ause of a tive resear h in abdu tion around us, we started getting interested in spe ifying a garbage olle tor in an abdu tive formalism.Within this formalism, one has the possibility to express the logi al relationship between obje ts in this ase e.g. the heap before and after olle tion without having to implement a parti ular algorithm. Indeed, there is only a little point in implementing the same algorithm in Prolog as in C, as one is bound to make the same on eptual errors. And while a garbage olle tor written in Prolog des ribes one parti ular instan e of an algorithm, in pra ti e, one is also interested in the whole lass that a generi algorithm represents. So we made an attempt at spe ifying a generi and abdu tive garbage olle tor: see se tion 5. Two instan es of it will spe ify the sliding olle tor ( ompletely) and the lass of opying olle tors. We will also spe ulate that by giving onstraints on the order in whi h fa ts an be abdu ed, one a tually an re onstru t the lassi al algorithms of Morris and Cheney, and given strong enough ompile time garbage olle tion they will have the same spa e performan e as an imperative spe i ation of the same algorithms. 3 redire tion of pointers is more involved in the garbage olle tion ontext than in the expansion ase 4 BinProlog and XSB had/has both a sliding and a opying olle tor 2 Dumping the sta ks as Prolog fa ts We implemented a (builtin) predi ate print all sta ks/0= and also made it possible that the same fun tionality is alled from within e.g. gdb. It produ es les LSi, HEAPi, CPi, TRi, REGSi when print all sta ks/0 is alled for the i-th time during a parti ular run of the system. 5 These refer to the lo al sta k, heap, hoi e point sta k, trail sta k and WAM registers. There was also fun tionality to print these sele tively (i.e. some portions of some of the sta ks). Some small samples from these les should be enough to get the gist; from HEAP: heap( 27, not_marked, fun t, '_$abort_ utpoint'/1). heap( 28, not_marked, int , 72). heap( 29, not_marked, fun t, ':-'/2). heap( 30, not_marked, stru t-ref_heap, 27). heap( 31, not_marked, atom , 'true'). From LS: ls( 57, not_marked, ref_ls, 50). ls( 58, not_marked, ode, 136162920-putpbreg). ls( 59, not_marked, int , 224). ls( 60, not_marked, atom , '| ?'). ls( 61, not_marked, int , 1). ls( 62, not_marked, int , 260). ls( 63, not_marked, ref_ls, 63). The rst argument is the index in the array used for implementing the sta k; the se ond argument indi ates whether the entry is marked or not 6; the third argument des ribes what sort of item is there and the last one its value. Most symbols are self-explanatory. putpbreg is an XSB spe i abstra t instru tion. The building of su h printing routines is an art in itself on whi h we'll not dwell too mu h here: depending on the desired level of a ura y of the printing routines and the a tual optimisation of the representation, it might take a lot of e ort to get at fa ts as above. But one also wants to ater for impossible data, i.e. sta k ontents that o ur in abnormal (read: buggy) situations, e.g. when garbage olle tion has in orre tly relo ated a pointer to the heap, to a pointer in between heap and lo al sta k (whi h is a relevant thing to onsider in the ontext of the sta k allo ation of XSB). So, the dump ould ontain things like: ls( 666, marked, between_h_ls, 17/23). where the 17 means the index from the start of the heap and 23 is rom the start of the lo al sta k. This is useful, be ause the origin of su h a between h ls pointer ould be either the lo al sta k or the heap. We also employed a ategory of unexpe ted pointers; so the output heap( 137, not_marked, strange, 123). heap( 138, not_marked, ref_nowhere, 4). would indi ate a strange tag and a referen e into a non-identi able region. Su h output usually indi ates a bug, an obje t the printing routines are not yet aware o or a badly understood invariant. It is important that the printing routines don't stop printing at the rst o urren e of something unusual: later strange things might make it easier to nd the origin of the problem. Both in XSB and BinProlog, every entry in the sta ks is tagged, so that an entry an be printed in isolation. When there are entries on the sta k that are not tagged and have no wrapping entries on the same sta k (like in ilProlog) it be omes mu h more diÆ ult to make sense of them. Anther issue is that we want su h a sta k dump to be possible at (almost) any moment during the olle tion pro ess and even general exe ution. E.g. after (or during) marking, in between the upand down-ward phase of a sliding olle tor or in the middle of a opying pro ess. There is one problem with the idea of the Prolog syntax: on e it is stated expli itly that sta k dumps must be in Prolog, it seems so obviously right that the statement itself be omes pedanti . 5 for XSB there is also a CHATi, while BinProlog la ks LSi 6 sin e the dump was done before a marking took pla e, everything is unmarked 3 Simple queries on the dumps Che king elementary invariants is quite easy by means of a Prolog query now, e.g. it is a WAM invariant that all stru tures are on the heap, whi h means that whenever a stru t-X (a pointer with a stru ture tag) is found, the X should be ref heap and it should point to a heap ell whi h ontains a fun t. The orresponding query to he k this is at the left: ?stru t_pointer(I,WhereTo,Index), ?heap(N,_,list-ref_heap,I), (WhereTo = ref_heap -> true ; error(I,Index)), \+((heap(I,_,_,_),heap(I+1,_,_,_))), heap(Index,_,What,_), error(list_points_not_in_heap(N)). (What = fun t -> true ; error(I,Index)). stru t_pointer(I,WhereTo,Index) :( ls(I,_,stru t-WhereTo,Index) ; heap(I,_,stru t-WhereTo,Index) ; aregs(I,stru t-WhereTo,Index) ; p(I,_,stru t-WhereTo,Index) ). At the right is a query that dete ts list tagged pointers (on the heap) that do not point to two onse utive ells that are not both on the heap: that situation ould result from an erroneously implemented builtin. More ompli ated invariants an be easily stated and he ked. In the ontext of garbage olle tion, the most ru ial property of a ell is whether it is rea hable from the root set. So, we implement a predi ate rea hable/1 whi h given a dump an generate all rea hable ells on the heap, or test the rea hability of a parti ular ell. The following program spe i es this property: :table is_rea hable_from/2, rea hable/1. rea hable(Cell) :root(Root), is_rea hable_from(Cell,Root). is_rea hable_from(A,B) :is_rea hable_from(A,B) :A = B. heap(B,_,stru t-ref_heap,N), is_rea hable_from(A,B) :is_rea hable_from(A,N). heap(B,_,list-ref_heap,N), is_rea hable_from(A,B) :( is_rea hable_from(A,N) heap(B,_,fun t,Name/Arity), ; is_rea hable_from(A,N+1) between(X,B+Arity+1,B+Arity+N), ). is_rea hable_from(A,X). Note that the se ond argument of heap=4 was ignored in the above ode: rea hable=1 is indeed meant to he k rea hability independent of the a tual marking phase. It is lear that rea hable=1 ould have been written without resorting to tabling: one just has to program the loop he k 7. But it is also lear that with tabling, rea hable=1 is easier to write, easier to understand as orre t and even more eÆ ient, sin e we use it often, as in the following program whi h he ks whether the marking phase has indeed marked all and only the rea hable ells. he k_marking :heap(I,marked,_,_), \+(rea hable(I)), error(marked_but_not_rea hable(I)). he k_marking :heap(I,not_marked,_,_), rea hable(I), error(rea hable_but_not_marked(I)). Rea hable/1 is also tabled, so that when it is alled with ground argument, XSB su eeds it at most on e. 7 loops an o ur be ause the implementation supports rational trees, or simply doesn't do o urs he k, or be ause the heap is orrupted by bugs 4 A sliding olle tor in Prolog We will spe ify a sliding olle tor for a Prolog heap (see [10℄, [2℄). Assume the (old before olle tion) heap was dumped in Prolog list format, then the predi ate sliding g /4 will produ e the new (after olle tion) heap as a list as well. % sliding_g /4: argument 1 and 2 are the old (input) and new (output) heap % argument 3 is the next index in NewHeap (input) % argument 4 is the translation table for the indi es (input) sliding_g ([℄,[℄,_,_). sliding_g ([old_heap(N,ref_heap,M)|RestOldHeap℄,NewHeap,NextI,TransTable) :rea hable(N), NewHeap = [new_heap(NextI,ref_heap,NewM)|RestNewHeap℄, putin(TransTable,N->NextI,T1), putin(T1,M->NewM,NewTransTable), sliding_g (RestOldHeap,RestNewHeap,NextI+1,NewTransTable). sliding_g ([old_heap(N,atom,Name)|RestOldHeap℄,NewHeap,NextI,TransTable) :rea hable(N), NewHeap = [new_heap(NextI,atom,Name)|RestNewHeap℄, putin(TransTable,N->NextI,NewTransTable), sliding_g (RestOldHeap,RestNewHeap,NextI+1,NewTransTable). sliding_g ([old_heap(N,WhatTo-ref_heap,M)|RestOldHeap℄,NewHeap,NextI,TransTable) :rea hable(N), (WhatTo = list ; WhatTo = stru t), NewHeap = [new_heap(NextI,list-ref_heap,NewM)|RestNewHeap℄, putin(TransTable,N->NextI,T1), putin(T1,M->MM,NewTransTable), sliding_g (RestOldHeap,RestNewHeap,NextI+1,NewTransTable). sliding_g ([old_heap(N,fun t,Name/Arity)|RestOldHeap℄,NewHeap,NextI,TransTable) :rea hable(N), NewHeap = [new_heap(NextI,fun t,Name/Arity)|RestNewHeap℄, putin(TransTable,N->NextI,NewTransTable), sliding_g (RestOldHeap,RestNewHeap,NextI+1,NewTransTable). sliding_g ([old_heap(N,_,_)|RestHeap℄,NewHeap,Pla e,TransTable) :\+(rea hable(N)), sliding_g (RestHeap,NewHeap,Pla e,TransTable). The above ode implements a sliding olle tor (although by Prolog's nature not an in-pla e one) and sin e also Morris' algorithm does so, one an wonder to what extent the above Prolog ode hides and/or ontains Morris' algorithm. First of all, the above ode shows no separate marking phase: the imperative des ription of Morris' algorithm exe utes a marking algorithm rst, be ause it is too diÆ ult to des ribe it otherwise. The ode above exe utes marking as a result of the exe ution of the rea hable/1 goal and the role of tabling is very prominent: the mark bits so essential in the eÆ ient imperative des ription are allo ated and implemented by the tabling me hanism; the tables indeed remember whether a heap entry is marked or not. Should we hope for an automati transformation from the en oded information in the table to the more eÆ ient imperative representation ? Or should we a tually wonder whether the potentially more dense tabled information is more eÆ ient than allo ating one bit per heap entry ? For us, the issue is not lear ut. The relo ation of root pointers an be implemented in more than one way: a separate pie e of ode ould use the translation table that is build up. But in the spirit of Morris, one ould add the root set (virtually) at one end of the heap. We have kept deliberately the third argument of sliding g /3 as an abstra t data type and not given ode for putin/3. This argument is meant to hold the translation of old heap addresses to new heap addresses. One annot see the Morris upward and downward pass in the Prolog ode above; on the ontrary: the above ode does only one pass and it is a downward pass. However, imagine that the uni ations NewHeap = ... are delayed, as well as the alls to putin/1, until after the re ursive all to sliding g /4, then it be omes more plausible that the two-pass algorithm is indeed lose. Together with the right implementation of the abstra t data type of the TransTable, one might retrieve a Morris' algorithm, but still not in-pla e. However, the old heap is in the terminology of the Mer ury destru tive input while the new heap is unique output. This means that the list representing the old heap an be reused by the newly onstru ted new heap and nally we do have an in-pla e sliding olle tor using LP te hnology ! The above is partially spe ulation, but we believe that it is worth exploring further. Note also that to a hieve some of the needed transformations from our Prolog program to the imperative Morris algorithm, it might be ne essary to let ompile-time garbage olle tion reason about run time sta k frames (environments that build up in the version in whi h the re ursive all is not in tail position) as well as data stru tures, or alternatively that one might have to make environments or ontinuations expli it in the Prolog ode perhaps by a binarization transformation like in BinProlog. We have in a similar style a Prolog version of a opying olle tor based on Cheney's algorithm and similar remarks apply there. We ould have written the olle tor above in many di erent ways, e.g. by having the marking ompletely before the sliding, or not by building up the lists of old and new heap, but by using the heap/4 fa ts dire tly and asserting new heap fa ts. The above however is one of the versions that omes to mind naively and is obviously orre t: sin e debugging another olle tor was the original purpose, (exe utable) orre tness had to be the most desirable property of the Prolog version olle tor. However, in se tion 5 we will see a di erent level of spe i ation and orre tness. 5 A set of abdu tive opying olle tors The ode for the sliding olle tor in se tion 4 is reasonably de larative: it ombines the advantage of being exeutable with a high degree of de larativeness. However, it implements one parti ular garbage olle tion algorithm, whi h is moreover deterministi in the sense that the relationship between the old and new heap is ompletely determined. This is not the ase for other algorithms e.g. opying ompa ting, whi h allow for di erent new heaps, depending on whether one uses a depthrst or a breadthrst opying algorithm, and depending on the order in whi h root pointers are treated. Sliding has no su h non-determinism: on e marking is done, there is only one possible new heap. Clearly, Prolog is not a good language to express su h non-determinism. In an abdu tive setting (see for instan e [9℄), one an spe ify the relation between the old and the new heap, without a spe i ation of how this relation is to be realised. Moreover, the natural setting is by making the heap after olle tion an abdu ible (also alled open) predi ate, say new heap/3. Also the orresponden e between the heap before and the heap after olle tion needs to be made expli it, and this is a hieved by the abdu ible predi ate transtable/2 8, whi h gives for any non-garbage ell the orresponden e between its old and new address. The abdu tive spe i ation allows for non-determinism in the sense above. We start by spe ifying all new heaps that an orre tly result from a olle tion, given a parti ular old heap (old heap/3) and a de nition of rea hability (rea hable/1). :open_predi ate(transtable/2), open_predi ate(new_heap/3). % ensure that the new heap is % ensure that the new heap % filled from the first entry % does not have holes (exists X: transtable(X,1)) <(exists X: transtable(X,Y)) <rea hable(_) transtable(_,A), transtable(_,B), A < Y, Y < B 8 one an give an abdu tive spe i ation without transtable/2, but it is very lumsy % ensure that a rea hable ell is " opied" at most on e <transtable(A,A1), transtable(A,A2), A1 =\= A2 % ensure that ea h rea hable ell is " opied" at least on e (exists Y: transtable(X,Y)) <rea hable(X) % ensure that the opy ontains the orre t ontents new_heap(M,SorL-ref_heap,R) <new_heap(M,ref_heap,R) <old_heap(N,stru t-ref_heap,S), old_heap(N,ref_heap,S), (SorL = stru t ; SorL = list), transtable(N,M), transtable(N,M), transtable(R,S), transtable(R,S), rea hable(N) rea hable(N) new_heap(M,ForA,V) <old_heap(N,ForA,V), (ForA = fun t ; ForA = atom), transtable(N,M), rea hable(N) % su essive fields in a stru ture or list ons must remain su essive <<old_heap(N,fun t,Name/Arity), old_heap(N,list-ref_heap,R), rea hable(N), rea hable(N), transtable(N,N1), transtable(R,R1), 0 < X, X =< Arity, 0 < X, X =< 2, Y is N + X, Y is N + X, transtable(X,X1), transtable(X,X1), N N1 =\= X X1 R R1 =\= X X1 The above formulation of a garbage olle tion pro ess allows for many orre t new heaps orresponding to the same heap before olle tion and parti ular rea hability. In parti ular, it allows for a sliding olle tor whi h an be enfor ed by the onstraint whi h retains the order of heap ells: <rea hable(N), rea hable(M), N < M, transtable(N,N1), transtable(M,M1), M1 < N1 Without this onstraint, the order is not ne essary retained and the resulting olle tors orrespond to so alled opying olle tors. The above spe i ation makes (must make !) expli it usually hidden assumptions about a garbage olle tor, e.g. that ea h obje t, even if rea hable from more than one root ell, should end up only on e in the WAM heap after olle tion. The above spe i ation does not allow for what is alled semanti garbage olle tion, neither for term ompression during the olle tion. But the onstraint where this restri tion is put is learly visible. The use of the abdu tive spe i ation is urrently restri ted to he king instead of generating: indeed, urrent abdu tive exe ution me hanisms su h like SLDNFAC are probably not able to ompute new heaps within a reasonable time. Also in this setting, we an wonder whether lassi al algorithms an be derived. The in-pla e sliding olle tor requires that it is possible to put a onstraint on the order in whi h new heap fa ts are abdu ed: indeed, the idea would be to let a new heap fa t reuse the spa e o upied by an old heap fa t; so the onstraint on the order of deriving the new heap fa ts should ertainly in lude that the orresponding old heap fa t is no longer needed. For deriving a opying ompa ting olle tor whi h leaves forwarding pointers in the old heap it would be ne essary to let the forwarding pointers whi h reside in the transtable/2 fa ts reuse the old heap fa ts. Apart from the fa t that su h reuse reasoning is not straightforward in general, there is the extra obsta le that within an abdu tive theory, there are no ways to guide the abdu tive pro ess. Still, we think these issues are worth to investigate further. 6 Con lusion Apart from an aid during the debugging of the garbage olle tors, Prolog dumps of the sta ks have helped us many times in dis overing bugs in the implementation of builtin predi ates, like e.g. opy term/3, and in nding memory leaks in builtin predi ates. So their use is quite wide. It is lear that we have simpli ed ertain issues: we have not dealt with early reset, variable hain ollapsing, trail ompa tion during garbage olle tion et .. But it is lear that these an be treated in Prolog as well as in the abdu tive approa h. At ILPS'91, while talking at the bar, we suggested that the garbage olle tor (of a parti ular Prolog system) ould have been written in Prolog itself. The idea aused laughter: writing a garbage olle tor for Prolog in Prolog was learly absolutely, totally and in all other ways, in on eivable 9. But ever sin e then, we have wondered whether it really isn't the right thing to do. The disadvantage is obviously performan e and also, how an one be sure that the garbage olle tor is not going to over ow the heap, ausing itself to be alled ? So there is de nitely a hallenge there. However, the Prolog version has a bigger han e of being orre t. It will provide more insight in the garbage olle tion pro ess and it will perhaps help in understanding how seemingly totally imperative algorithms an be re onstru ted from within the LP framework, be it Prolog or abdu tion. We will ontinue resear h in this dire tion. A knowledgements We want to thank Geert Engels, Paul Tarau and Kostis Sagonas for the pleasant ollaboration while working on the garbage olle tors of BinProlog and XSB respe tively. The BIM Prolog experien e was also essential for this paper, but rather painful, so we'll omit names. Referen es 1. H. A t-Ka i. Warren's Abstra t Ma hine: A Tutorial Re onstru tion. The MIT Press, Cambridge, Massa husetts, 1991. See also: http://www.isg.sfu. a/~hak/do uments/wam.html. 2. K. Appleby, M. Carlsson, S. Haridi, and D. Sahlin. Garbage Colle tion for Prolog Based on WAM. Communi ations of the ACM, 31(6):719{741, June 1988. 3. Y. Bekkers, O. Ridoux, and L. Ungaro. Dynami Memory Management for Sequential Logi Programming Languages. In Y. Bekkers and J. Cohen, editors, Pro eedings of IWMM'92: International Workshop on Memory Management, number 637 in LNCS, pages 82{102, St. Malo, Fran e, Sept. 1992. Springer-Verlag. 4. C. J. Cheney. A Nonre ursive List Compa ting Algorithm. Communi ations of the ACM, 13(11):677{678, Nov. 1970. 5. B. Demoen, G. Engels, and P. Tarau. Segment Preserving Copying Garbage Colle tion for WAM based Prolog. In Pro eedings of the 1996 ACM Symposium on Applied Computing, pages 380{386, Philadelphia, Feb. 1996. ACM Press. 6. B. Demoen, G. Janssens, H. Vande asteele. Exe uting Query Flo ks for ILP. Pro eedings of BENELOG'99, Maastri ht, 5 November 1999 7. B. Demoen and K. Sagonas. Memory Management for Prolog with Tabling. In Pro eedings of ISMM'98: ACM SIGPLAN International Symposium on Memory Management, pages 97{106, Van ouver, B.C., Canada, O t. 1998. ACM Press. 8. B. Demoen, K. Sagonas. Heap Garbage Colle tion in XSB: Pra ti e and Experien e Pro eedings of the Se ond International Workshop on Pra ti al Aspe ts of De larative Languages (PADL'00), Boston, Jan. 2000, pp. 93{108 9. M. Dene ker, and D. De S hreye. SLDNFA: an abdu tive pro edure for normal abdu tive programs J. Logi Programming 34 (1998), no. 2, 111-167. 10. F. L. Morris. A Timeand Spa e-EÆ ient Garbage Compa tion Algorithm. Communi ations of the ACM, 21(8):662{ 665, Aug. 1978. 9 thank you William Goldman